1. Field of the Invention
The invention relates generally to authentication of computers which access storage controllers and configuration of such storage controllers. The invention deals more particularly with a technique to dynamically authenticate such computers on a network and configures such storage controllers with address information typically required for remote configuration by such computers.
2. Description of the Related Art
Virtual Private Networks (VPNs) are popular today because they join together multiple private networks without using dedicated network links between the private networks. The VPN environment requires initial authentication between the peers and then Internet Key Exchange (IKE) and IP Security (IPSec) protocols to provide data security between two VPNs. IKE is well known in the industry and allows two security peers to exchange a series of security keys. IKE is described in Request for Comment 2409, which is hereby incorporated by reference as part of the present disclosure. IPSec is an industry standard that allows its peers to encrypt an IP datagram and to authenticate the sender of the datagram. It can be used to encrypt the content of the datagram and/or a destination IP address. Thus, it provides a means to protect the identities of its peers. It typically uses IKE to establish initial set of encryption keys. IPSec is described in RFCs 2401, 2410 and 2411, which are hereby incorporated by reference as part of the present disclosure.
In order to initiate IKE transactions, security peers must first authenticate each other. IKE proposes four different authentication methods: digital signature, two forms of public key and pre-shared key. Digital signature and public key are accessible by the public and are published periodically by the organizations that use them. They are distributed using Public Key Infrastructure which stores digital certificates and signatures. When a receiving peer receives a request to initiate a security key exchange, it validates the given certificate/signature against a trusted database that stores the most recent published certificate. Once the certificate is validated, the receiving peer will continue key exchange process. In a network environment, it is not always possible to have access to a public key infrastructure in which digital signatures or certifications are stored. It is also possible that a chosen IP security tool kit for a device does not provide full-fledged implementation of IKE and IPSec protocol. When either condition occurs, it would be beneficial for the target device to be able to dynamically authenticate the proper host and to establish a secured data path between them.
Unlike digital signature and public key, preshared keys are not widely published but are predetermined among a group of trusted peers. The preshared keys are assigned to each peer in the group and statically associated to specific IP addresses of the respective peers. Many organizations using VPN adopt preshared keys because they only want to communicate with specific VPN peers, and the IP addresses of these other, specific VPN peers are known from the start. However, certain types of target devices such as RAID storage controllers may need to communicate with a large number and wide range of hosts. Also, the hosts may be dynamically added or removed from the network. In such an environment, it is difficult to know, before the communication, the IP address of each host with which each storage controller may need to communicate.
There are two forms of IKE—Main Mode and Aggressive Mode. According to the Main Mode, IKE divides key exchanges into two phases. In phase one, the IKE protocol establishes a security association by exchanging encryption algorithm proposals, a hash algorithm, Diffie-Hellman public values, a method of authentication and auxiliary data. One example of “Diffie Hellman” public values is described in RFC 2631. Once the security association is agreed by the devices and established, all further transactions are protected with the agreed encryption keys for phase two negotiation, that is specific to the actual security service, as follows. In phase two, a set of dynamic security keys is negotiated for a specific security service, in this case the IPSec protocol. These dynamic keys are established based on the security components supported by each peer and are regenerated based on either the amount of data transferred or time elapsed. After the keys are generated, IKE automatically creates inbound and outbound security associations between the two peers based on the security policy defined on each peer. From this point on, all IP datagrams transferred between the two peers are encrypted and/or authenticated by the IPSec protocol. As described so far, security is established at the device level. This means that any application from the physical device such as the secured host computer can send information across an unsecured Ethernet to the target such as the storage controller, and the data cannot be understood or manipulated by any other device. However, this will not prevent a malicious application on the secured host computer from sending a damaging configuration command to the storage controller. Therefore, the security process continues at the application level to prevent unauthorized applications on the secured host computer from establishing a configuration session with the storage controller. The iSCSI protocol is used as the means to transfer configuration commands and responses. As a part of iSCSI login process, the initiator, i.e. proper application on the secured host computer, must supply a login name to be authenticated by the target, i.e. storage controller. This name is predetermined and was agreed by the initiator and the target when a storage system was initially set up. In a typical scenario, each organization will select a unique name shared by all its storage systems. Without the correct name, the target will refuse any unauthorized login request so that the unauthorized iSCSI session cannot be established. The content of the name is protected by IPSec when it is transferred across the network.
The Aggressive Mode of IKE is an alternative to Main Mode during phase one negotiation. The difference between the two modes is mainly in identity protection. IKE's Main Mode separates key exchange information from identity and authentication information. The Aggressive Mode, on the other hand, transfers the key exchange information with the identity information, and thereby exposes the identity information. Furthermore, the Aggressive Mode can only propose one encryption algorithm at a time. The target can either accept or reject the offer. With the Main Mode, the initiator can offer multiple encryption algorithms, and the target can pick and choose one of the proposed algorithms. The benefits of using the Aggressive Mode are speed and support of remote access but the disadvantage is lesser protection of identity.
In both the Main Mode and Aggressive Mode, IPSec allows security peers to authenticate each other and to encrypt data transferred across an unsecured Ethernet using the keys generated from the IKE transactions. There are multiple IPSec protocols including encapsulated Security Payload (ESP) and Authentication Header (AH). AH proves the origin of a data packet and data integrity and prevents replay. ESP provides the same protections of AH plus data confidentiality. Both AH and ESP require cryptography such as DES in CBC mode. IPSec requires shared keys to perform authentication and/or confidentiality; these can be provided by IKE as explained above. There are two modes of IPSec—transport mode and tunnel mode. An original IP packet contains IP header-TCP header-Data, a transport mode contains IP header-IPSec header-TCP header-Data and a tunnel mode contains IP header-IPSec header-IP header-TCP header-Data. The transport mode protects upper layer protocols. An IPSec header is inserted between an IP header and an upper layer protocol header. The transport mode may be used where the communication endpoint is the same as the cryptographic endpoint. The tunnel mode protects entire IP datagrams. A complete IP packet is encapsulated in another IP datagram and an IPSec header is inserted between the outer and inner IP headers. Tunnel mode may be used where the communication destination is also the cryptographic destination, and by security gateways (such as routers and fireballs) to provide security services on behalf of VPN. When tunnel mode is used by the security gateways, the communications endpoints are specified in an inner header that is protected, and the cryptographic endpoints are specified in the outer IP header. A security function in a gateway decapsulates the inner IP packet after IPSec processing and passes the remaining packet to its final destination. IPSec can be implement with a modification of an IP stack to support IPSec natively. A structure called a Security Association (SA) may be used to associate security services and a key with the communications to be protected by the remote peer which exchanges the IPSec communications. Such an association is helpful to encapsulate and decapsulate IPSec packets. Each SA provides security services in one direction only and has parameters called Security Parameter Index which include the IPSec protocol header, a IPSec protocol value and a destination address to which SA applies. Typically, there are parameters for two SAs, one in each direction. (IKE also uses the concept of SA, but has a different format. An IKE SA defines how two peers communicate such as which algorithm to use to encrypt IKE communications and how to authenticate a remote peer. The IKE SA then produces an IPSec SA between the two peers.)
After authenticating a host computer in VPNs or other environments, it may be necessary to configure the target device. Difficulties have arisen in configuring devices which do not have the appropriate network parameters such as (a) an IP address, (b) a subnet mask to indicate which grouping of IP addresses pertains to the device and/or (c) a Gateway address which is needed when the device sends a datagram outside of its own subnet. An existing DHCP protocol dynamically assigns an arbitrary IP address to a target device on a local subnet, when the IP address is lacking. This dynamic assignment is implemented by the following procedure. A host on the local subnet is designated as the DHCP server. All controllers get their IP addresses from this local host. A lease time is assigned to the IP address where the IP address is valid for this lease time. At the end of the lease, a new IP address is generated for the controller. This dynamic assignment becomes the “static” IP address of the target device for the lease time for purpose of configuration and is used by others on other subnets and across the WWW. A problem with this approach is that the IP address changes when the lease runs out. Servers and controllers on a network are generally assigned a static IP address on an IP network for this purpose. If a controller is to be accessed from the WWW, the network address must remain static.
An object of the present invention is to dynamically authenticate hosts and other computing devices and establish a secure link between them and their targets.
Another object of the present invention is to provide such dynamic authentication where digital signature, public key and statically-assigned preshared keys are not available.
Still another object of the present invention is to allow dynamic discovery and configuration of a target device on a network.